The Universal Datagram Protocol (UDP) and the Transmission Control Protocol (TCP) are transport protocols known in the art for communication over the Internet. UDP sends data at a fixed rate with the only constraints being the rate of data generation by the application and bandwidth availability on the network. The characteristics of UDP make it an ideal candidate for use in voice over IP, video applications and other real-time applications. A problem with UDP arises when the number of streaming media applications on the network increases. With UDP, each application tries to capture the amount of bandwidth that satisfies its fixed sending rate requirement. This often leads to problems of unfairness and the danger of congestion collapse of the network. The unfairness problem in UDP arises due to the lack of an end-to-end congestion control.
The TCP protocol is a reliable transport protocol that promises guaranteed delivery. It is connection-oriented, establishing a full duplex virtual connection between two end points. The TCP protocol at the transport layer breaks the application data into chunks of best decided size called segments, along with overhead information such as the source and destination port number, sequence number, etc. Once the segment is sent, a timer is set and waits for the receiver to acknowledge (ACK) the segment. If an ACK is not received before the timer expires, TCP retransmits the segment. TCP also maintains a checksum on its header and data to ensure the packet's integrity while in the network. Packet reordering is also performed if necessary to ensure data reception in correct order by the end application. The chief feature of TCP is its flow and congestion control. Flow control checks for buffer space at the end systems and slows down the data transfer rate if the buffer capacity is reached. Hence, TCP limits the sender to send only as much data as the receiver can handle. Flow control only prevents the sender from overflowing the receiver's buffer, but it does not take into account the buffers of intermediate nodes, i.e., network congestion. To solve the problem of overloading the network nodes between end systems, TCP implements a congestion control mechanism. While flow control is an end system issue, congestion control is a network issue. Congestion control implementations for TCP are known in the art. These congestion control implementations fall into two main categories, window-based and rate-based.
Window-based protocols are known in the art for use with TCP. For each connection, TCP maintains a congestion window (cwnd) state variable, which is the maximum number of packets outstanding in the network. In other words, cwnd refers to the maximum number of packets the sender can send at any time without waiting for an ACK. The congestion control mechanisms embedded in TCP methods and systems known in the art follow the additive increase/multiplicative decrease (AIMD) strategy whereby TCP probes for available bandwidth by increasing its cwnd size linearly, and responds to congestion on the network by decreasing its cwnd size multiplicatively. TCP interprets a timeout or packet loss as a sign of congestion and decreases the cwnd, while successful receipt of ACKs for all packets sent during the last round trip time (RTT) as a sign to increase the cwnd. Apart from congestion control mechanisms, congestion avoidance plays a great role in the real stability of the Internet. Both the mechanisms are basically resource management problems. The key to the congestion avoidance scheme is the algorithm used to increase or decrease the rate, allowing the network to operate in the optimal region of low delay and high throughput. The increase and decrease parameters are designated as α and β respectively, such that 0<α and 0<β<1 is satisfied. In TCP implementations currently known in the art, the values of these parameters are α=1 and β=½, meaning that the cwnd is increased by one every RTT and decreased by ½ its current value after a packet drop is detected.
Mechanisms have been proposed in the art to improve the network throughput, these mechanisms include, slow start, congestion avoidance, fast retransmit and fast recovery. These mechanisms are well known in the art and form the base of TCP Tahoe, Reno, New Reno and SACK. In particular, TCP SACK (Selective Acknowledgement) is a conservative extension of Reno's congestion control, in which it uses the AIMD strategy and minimal changes to other congestion control algorithms. TCP SACK is widely used in the industry, however, the problem with using TCP SACK for streaming applications resides in the multiplicative part of the AIMD strategy. As described, the TCP protocol changes its sending rate using a congestion control mechanism by backing off the sending rate on packet drops responding to congestion on the network. While TCP as served data-oriented applications quite well because these applications can tolerate variable delays and transmission rates, but require a very reliable service. On the other hand, real-time applications like voice and video have employed the UDP protocol because these applications can tolerate some loss but require minimal delay variations and smooth transmission rates, otherwise the user will perceive a degradation in the quality of the transmission in the form of interrupted voice and/or frozen images. Because real-time applications are delay sensitive and cannot tolerate a varying sending rate, TCP is not ideal for streaming applications and the use of TCP on the Internet has been limited to data transmission. Additionally, the reliability of TCP's retransmissions is useless for interactive real-time applications such as Internet Telephony and Voice Conference since retransmitted packets reach their destination too late for use by the system.
Voice over IP and video applications continue to increase the amount of real-time traffic over the Internet. These streaming applications utilize the UDP protocol because TCP has not proved to be suitable for streaming applications due to the use of a congestion control mechanism that can drastically change the connection's transmission rate, affecting the user-perceived quality of the transmission.
The TCP-friendliness problem has also been widely investigated. Solutions can be broadly classified as either end-to-end or router-based depending on where the solution is implemented. The transport layer protocols previously described belong to the end-to-end category. Although each protocol is adequate for the types of applications it serves, they have not been shown to work together. It is well known that during congestions events, when TCP and UDP share the same bottleneck link, UDP is not fair to TCP, obtaining a disproportionate share of the bandwidth. Since the number of streaming applications and multimedia traffic over the internet is growing, this TCP-friendliness problem continues to become more relevant. The need for an end-to-end congestion control for streaming applications has been identified as a solution to the fairness problem and the congestion collapse problem on the internet.
Accordingly, in spite of the deficiencies that are inherent in the use of TCP with streaming applications, the use of these end-to-end flow and congestion control mechanisms for streaming applications has been acknowledged as an important measure to ease or eliminate the unfairness problem that exists when TCP and UDP share the same congested bottleneck link and a means to overcome the congestion collapse problem in the Internet.
Accordingly, what is needed in the art is a system and method that provides better performance than TCP systems currently known in the art for data applications and smooth enough transfer rates for streaming media applications.
However, in view of the prior art considered as a whole at the time the present invention was made, it was not obvious to those of ordinary skill in the pertinent art how the identified need could be fulfilled.